O projeto fênix - resenha crítica

Bill promovido

Bill está dirigindo a 16 km/h acima do limite de velocidade. Ele está atrasado para o trabalho. Passou a manhã no consultório com o filho. Seu celular tocava toda hora. Era o pessoal da empresa. A marca está sofrendo com interrupções ocasionais na rede. Ele é o diretor de Operações de Tecnologia de Médio Porte.

É o responsável por um grupo de TI pequeno na varejista Parts Unlimited. Ele acompanha os problemas de rede. Caso as coisas não deem certo, as pessoas culparão Bill. Ele recebe uma ligação do RH e se preocupa com a possibilidade de ser demitido.

Laura, a vice-presidente de RH, comunica a Bill que ele terá uma reunião com Steve Masters, o CEO da empresa. Em vez de ser demitido, Bill recebeu uma boa notícia. Ele virou o vice-presidente de operações de TI. No entanto, no fundo, ele não ficou feliz com a novidade.

O projeto fênix

A promoção o pegou de surpresa. Ele sabia que a carreira dos VPs de Operações de TI não durava muito. O cargo tinha uma rotatividade alta. Ele se reportaria diretamente a Steve. Sua missão é garantir o sucesso do “projeto fenix”, o software da Parts que viabilizaria as vendas. Steve contou que esse era o projeto central da empresa.

O futuro da marca dependia dele. Se o projeto desse errado, a empresa perderia os clientes e poderia deixar de existir. No íntimo, Bill não queria a promoção. Preferia seu cargo de apagador de incêndios do TI. No entanto, não soube dizer “não”. O novo VP não sabia nem por onde começar.

Toda a estrutura de TI estava fora de ordem. John Pesche, diretor de Segurança da Informação, criava continuamente incidentes de softwares. Todos tinham que trabalhar para corrigi-los. Às vezes, alguns desenvolvedores do setor trabalhavam com urgência para resolver os problemas antes das férias.

Erik Reid

Essa é uma crítica comum aos desenvolvedores: eles quebram coisas e somem, deixando o pessoal de Operações quebrando a cabeça para arrumar a bagunça. Os problemas acontecem porque o pessoal da Segurança da Informação pula os procedimentos de liberação e concentra-se no que parece ser importante aos auditores.

Já Patty McKee, diretora de Suporte a Serviços de TI, critica o fato de as mudanças não serem documentadas. O TI é uma zona. Bill deveria implementar o fênix em dez dias. No entanto, pouquíssimas tarefas foram concluídas. O TI está muito ocupado com assuntos emergenciais. As coisas começaram a mudar quando o VP conheceu Erik Reid.

Ele era um potencial membro do conselho da Parts e um figurão da tecnologia. Erik convidou Bill a observar o “Work in Progress” (WIP), ou seja, as tarefas que estão em andamento, mas que ainda não foram terminadas. Erik apresentou a “teoria das restrições”. Nela, o WIP é um assassino silencioso.

A teoria das restrições

Um problema comum que existe nas fábricas é o gargalo. Ele é um ponto de congestionamento. Quando a máquina que produz chapas em uma empresa automotiva quebra, a produção de todos os carros atrasa. A teoria das restrições trabalha para encontrar o gargalo e melhorá-lo sistematicamente até que ele não seja um problema.

Inicialmente, Bill teve restrições à ideia. Afinal, era uma teoria da gestão de fábricas. Não parecia ter nada a ver com o TI. No entanto, Erik deixou claro: o trabalho do VP de Operações de TI é garantir o um fluxo ininterrupto, previsível e eficiente de trabalho planejado. 

Isso só é possível com o mínimo de interrupções. Apagar incêndios não faria sentido. Qualquer melhoria que não incluísse o gargalo seria uma ilusão. A teoria das restrições incluía:

• Identificar a restrição: descobrir o gargalo que está atrasando todo o resto.
• Explorar a restrição: certificar-se de que a equipe fez o possível para economizar tempo nessa etapa. Trabalhar em prioridade alta.
• Subordinar a restrição: adaptar todo o processo à velocidade que a tarefa-gargalo consegue gerenciá-lo.

Os quatro tipos de trabalho

O gargalo do TI era o engenheiro-chefe, Brent Geller. Ele resolvia os problemas de toda a equipe. Por isso, mudanças muito simples levavam semanas para terminar. Essa era a restrição da marca.

Brent estava sempre sobrecarregado. Ele era usado 100% do tempo. Qualquer tarefa dada a ele ficava na fila, a não ser que fosse uma emergência. O segredo para melhorar as coisas era ajustar o ritmo do WIP ao gargalo. 

Para fazer isso Bill precisou entender os quatro tipos de trabalho:

• Projetos de negócios: as iniciativas oficiais da empresa.
• Operações de TI: o trabalho que vem dos projetos de negócio e as melhorias.
• Mudanças: as variações no desenvolvimento de TI.
• Trabalho não planejado: o apagar de incêndios. É o que mais compromete os prazos.

O trabalho não planejado

O trabalho não planejado é o pior tipo de trabalho. Ele é fruto dos gargalos. É preciso se livrar dele. Os imprevistos sempre existirão, mas precisamos evitá-los ao máximo. Outro problema que Bill enfrenta é a dificuldade de corresponder ao cronograma impossível de Steve.

Há pressão dos investidores e da gestão. Bill tenta pôr as ideias de Erik em prática e insiste para que haja mais prazo. No entanto, Steve insiste para que as coisas sejam feitas do jeito antigo. O fênix é lançado antes de estar pronto e fracassa.

Steve insistiu em sobrecarregar o engenheiro da equipe com trabalho não planejado. Depois de vários desentendimentos com o CEO, Bill se demitiu. Ele se sentiu frustrado ao não conseguir implementar as mudanças da gestão. Só que o projeto despencou ainda mais. 

O retorno de Bill

Já passamos da metade do microbook e, nesse momento da história, os departamentos voltaram a apagar incêndios. Eles jogam culpa um no outro. Por isso, a gestão se esforçou para trazer Bill de volta. Com um bônus atraente, ele voltou. Dessa vez, ele e Steve tentaram se entender. 

O CEO acreditava que uma equipe poderia ter cinco disfunções principais:

• Falta de confiança: dificuldade de demonstrar vulnerabilidade em grupo.
• Medo de conflito: criar uma harmonia artificial no lugar de um debate construtivo.
• Falta de comprometimento: a falsa adesão às decisões do grupo cria confusão.
• Evitação da responsabilidade: fugir das consequências das próprias ações.
• Desatenção aos resultados: focar só em si e desconsiderar a empresa.

A reunião com Steve não resolveu tudo. No entanto, Bill percebe que toda a equipe está junta em torno de uma solução. A equipe começou a adotar o DevOps, uma abordagem de gestão para acelerar o tempo de lançamento no mercado e flexibilizar o trabalho.

Implementando o DevOps

O DevOps é o uso dos princípios de metodologias Lean ao fluxo de valor no mundo do TI. As metodologias Lean são uma adaptação do Sistema Toyota de Produção ao desenvolvimento de software. A ideia é trazer ideias como eliminação de desperdícios e entrega contínua ao TI.

O DevOps se baseia em ideias de gestão solidificadas por mais de um século. Em vez de sua aplicação se dar para produtos físicos, de fábrica, ela acontece para softwares. É a revolução da fabricação adaptada à era dos programas de computador. Em vez de a transformação acontecer nos bens da indústria, ela acontece no fluxo de valor de TI.

No sistema Toyota, surgem ideias como:

• reduzir o tamanho das entregas;
• diminuir o trabalho em processo;
• encurtar o tempo entre os ciclos de feedback;
• aumentar sua frequência.

Isso trouxe um aumento considerável na produtividade das fábricas, na satisfação do público e na qualidade do que estava sendo vendido.

As três maneiras

Erik ensinou a Bill “as três maneiras”, os princípios por trás do DevOps:

• Primeira maneira: descobrir como criar um bom fluxo de trabalho, que vai do Desenvolvimento para Operações de TI.
• Segunda maneira: ter loops de feedback mais curtos, corrigindo os problemas na origem e cortando o retrabalho.
• Terceira maneira: criar uma cultura que promova a experimentação, a repetição e o aprendizado com os erros.

Na primeira maneira, o foco é criar um fluxo rápido de trabalho entre o Desenvolvimento e as Operações. Uma forma de fazer isso é com um quadro Kanban. Essa é a técnica de usar post-its para acompanhar o ritmo de produção do TI. É um sistema de gestão visual.

Erik aconselhou Bill a usar o Kanban para controlar o WIP do Desenvolvimento e Operações de TI. A técnica também é herança da gestão de fábrica. Os gestores usam para deixar as tarefas visíveis. Ao reduzir o WIP, o Kanban ajuda as empresas a se manterem fazendo o trabalho correto. 

Uma empresa é como uma moto

Nesse momento, BIll já achava Erik parecido com o mestre Shifu, do Kung Fu Panda. Ele dava conselhos sábios, herdados da indústria fabril. No TI, mostravam-se um sucesso. O figurão da tecnologia contou também os segredos da segunda maneira. Ele disse que a empresa é como uma moto.

Se não fizer a manutenção regularmente, a moto apresentará problemas em algum momento. No TI, a “manutenção” está nos ciclos de feedback. O projeto fênix tinha intervalos de lançamento muito longos. Bill procurou trazer qualidade desde os estágios iniciais. Iria corrigir os problemas na fonte.

Para isso, precisava de ciclos de feedback rápidos. Erik chama isso de “fluxo de peça única”. Trabalhe uma parte por vez. Diminuir o tempo entre cada etapa é uma forma de maximizar o rendimento, diminuir o WIP e reduzir erros. Erik dizia que é impossível acertar o alvo se usarmos o canhão só de nove em nove meses.

Usando o feedback contínuo

Erik volta a usar a sabedoria fabril para ajudar Bill a implementar um sistema de feedback contínuo. Ele cita como exemplo a Toyota. Na década de 1950, a empresa tinha um processo de estampagem de capô cujas mudanças levavam quase três dias.

Isso congestionava as máquinas de estampagem. O que eles fizeram para mudar isso foi uma série de melhorias e preparações. Isso diminuiu o tempo de mudança para só dez minutos. É daí que vem o termo de gestão “troca rápida de ferramentas”. É preciso diminuir a lentidão para um ciclo de implementação veloz.

Os testes rápidos servem para garantir que o código sempre estará pronto para implementação. Ele não está finalizado depois da programação. É preciso testá-lo e ver se ele funciona conforme foi planejado. Erik ajudou Bill a olhar de forma mais ambiciosa o número de implementações que poderia fazer.

Os frutos do DevOps

Desde que os princípios de DevOps, das três maneiras e da teoria das restrições foram colocados em prática, as interrupções caíram em dois terços. A recuperação dos erros também ficou ainda mais rápida. Há um processo para sincronizar o Desenvolvimento e as Operações de TI. O fluxo de projeto ficou mais rápido.

O fênix está fluindo perfeitamente. Sem perceber, Bill também estava pondo a terceira maneira em prática. O TI da Parts aderiu a uma cultura de experimentação, erros e melhoria contínua. Os sistemas eram colocados à prova para que ficassem mais robustos. As entregas se tornaram mais completas.

Graças ao DevOps, a Parts conseguiu criar um código e uma infraestrutura resilientes em tempo recorde. A equipe de TI assimilou a cultura de correr riscos e aprender com os erros. A empresa saiu de sua posição delicada no mercado e ganhou projeção. Bill percebeu que TI não é só um departamento, mas uma habilidade.

Notas finais

Em Projeto Fênix, os autores usam um romance para ensinar como pôr o DevOps em prática e organizar o TI de uma empresa. O livro atende a um nicho específico, focando em pessoas de gestão ou dos departamentos de Desenvolvimento e Operações de TI.

Dica do 12min

As metodologias ágeis são implementadas por algumas das startups mais bem-sucedidas do mundo. Mesmo marcas consolidadas, como Dell, Spotify e Amazon se servem de seus princípios. Aprenda mais sobre elas em “Ágil do jeito certo”. Disponível no 12 min!